In the early days of mainframe computers, the concept of running software programs in batches of jobs was the norm. There were a limited number of computers, so users had to schedule their job(s) to run on the computer when the computer was not being used for some other, more important job. In such systems, each job was scheduled to run to completion without interruption, followed by the next job and then the next. The limited computer time available necessitated running lower-priority jobs “off-hours” so as not to delay higher-priority applications.
More recently, multi-tasking computer systems have allowed the concurrent or interleaved execution of two or more jobs by a single CPU. A multi-tasking computer system allows many applications to execute in the same general time period. Typically, multi-tasking systems have complex internal scheduling algorithms, wherein processes are scheduled in accordance with assigned priorities. However, the applications still contend for computing resources. To alleviate resource contention, an application in a multi-tasking system may be run off “off-hours” on an operator-scheduled basis.
The applications that are run off-hours may include maintenance jobs, such as backup, indexing, software updates, virus and malware scans and defragmentation. Candidates for off-hours processing may also include software applications that run reports, perform financial calculations, etc. However, some applications, such as indexers, should be run during production time. Therefore, not all applications are good candidates for off-hours execution.
Another problem with scheduling a job to run off-hours is that the computer may be turned off at the time the job is scheduled to run. A further problem is that some machines do not have clearly identified off-hours. For example, many computer systems are used twenty-four hours a day for a computing activity that is considered significant enough that the activity should not be interrupted for a substantial period. Therefore, there are no “off-hours” in which to schedule jobs. A still further problem is that typically a user has to determine when the job should be scheduled for off-hours computing. Thus, setting the schedule takes up a user's time and is subject to user error.
As previously mentioned, running the computing job can interfere with a user's ability to use the computer and can take resources away from other, possibly more pressing applications and jobs. Throttling is a technique for minimizing these negative impacts. Throttling prevents an application or job from using more than an allocated amount of resources. Types of throttling include disk I/O throttling, CPU throttling and network throttling. For example, CPU throttling can involve establishing a target CPU utilization limit for an application and forcing the application to stop working if the application exceeds the target limit. Throttling is sometimes applied to computer resources for maintenance applications or less important computing jobs. While throttling has benefits, the computing job's resource use is not totally transparent to other jobs and applications.
At the same time, it is observable that considerable computing resources go unused, even during the processing of urgent, top-priority jobs. The wide differences in the speeds of CPUs, memory, disk drives and networks typically cause one or more of these components to sit idle while one of the other components is fully consumed. A three-gigahertz CPU, for example, often sits idle while waiting for a disk drive to retrieve data at an average access time measured in milliseconds.
To recover and utilize these otherwise lost resources, what is needed is a technique that allows one or more jobs to execute in a computer system without significantly impacting other jobs or applications. The technique should not consume a user's time in scheduling the job nor should it negatively impact the user's interaction with the computer system when the job is running. The technique should not require scheduling the job to run off-hours. The technique should be utilizable by and beneficial to a computer system that has no off-hours.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.